Skip to content

Conversation

@Ph4ntomas
Copy link
Contributor

@Ph4ntomas Ph4ntomas commented Oct 5, 2025

The title say it all.

This PR adds TextInput widget, which will be useful as a building block for e.g. prompts.
On top of that, I've enabled support for key-repetition so the prompt themselves feel more natural.

TODO:

  • Basic TextInput integration
    • Transmit text in Key Events (very basic for the time being)
    • Enable key repetition
    • on_input event
    • on_submit event
  • Advanced TextInput integration
    • Styling support
      • Implements all & methods
      • Make gradient less unwieldy (add strongly typed angles & better color-stop handling)
    • Copy/Paste support -- This works. The clipboard itself is not set-up. Not sure if I'll set it up in this MR
    • cursor control from the config ?
    • Find a way to focus text input from the config
  • Rust configuration support
    • basic
    • advanced
  • Lua configuration support
    • basic
    • advanced
  • find & remove server-side except() and raw unwrap() Postponed to [API] Gracefully handle protobuf translation issues #370 Removed the ones from this PR.
    • add a TryFromApi trait so we can log error iso crashing.
  • Documentation
    • Rust
    • Lua

@Ph4ntomas Ph4ntomas force-pushed the snowcap-add-text_input-widget branch from 33b380b to 756d3af Compare October 6, 2025 05:31
@Ph4ntomas
Copy link
Contributor Author

  • find & remove server-side except() and raw unwrap()
    • add a TryFromApi trait so we can log error iso crashing ?

@Ottatop do you have thought on that ?

Most except and unwrap are justified in the sense that the config library should always produce 'correct' value, but IMO the server should be resilient to protocol error.

The second point is only for types without a default implementation.
If a default exist, I'd assume unwrap_or_default() to be called instead (tho we might tracing::warn! when that happen if a value was expected).

The alternative is to hardcode our own default when the translation between protobuf & iced types fails.

@Ottatop
Copy link
Collaborator

Ottatop commented Oct 7, 2025

do you have thought on that ?

Agree, it would be best to crack down on these panics (especially if anyone wants to make protobuf bindings), though I strongly recommend doing this in another PR seeing as this one's already up to 2.5k lines

@Ph4ntomas
Copy link
Contributor Author

Ph4ntomas commented Oct 7, 2025

though I strongly recommend doing this in another PR seeing as this one's already up to 2.5k lines

Agree, I'll only try to remove the ones introduced by this PR and removable :)

@Ph4ntomas Ph4ntomas force-pushed the snowcap-add-text_input-widget branch 14 times, most recently from 7998627 to d4aa251 Compare October 8, 2025 16:16
@Ph4ntomas Ph4ntomas marked this pull request as ready for review October 8, 2025 16:22
@Ph4ntomas
Copy link
Contributor Author

Ph4ntomas commented Oct 8, 2025

Allright, I think that's all.

FYI, the PR is on top of #364. because I needed some of the changes from that PR, and it makes for a cleaner history that cherry-picking the commits I need (plus the eventual rebase hell if I discovered some issue in that PR).

It should rebase cleanly should you choose to first pull the other one, and then rebase + merge this one (which could also be easier to review, I guess ?)

OTOH, you can also close the other one and track everything here if you prefer.

@Ph4ntomas Ph4ntomas force-pushed the snowcap-add-text_input-widget branch 6 times, most recently from 6944918 to f4196da Compare October 12, 2025 07:00
Comment on lines +53 to +58
message Background {
oneof background {
Color color = 1;
Gradient gradient = 2;
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm having second thought on this.

It matches iced implementation, and will allow future addition of gradient without code duplication, but the current widget have a standalone background_color, which make me think the goal might've been to have a backround_gradient or a background_linear field instead.

I don't feel strongly about which solution ends up implemented, but IMO if this is merged as it is before 0.2 gets out, we should realign other widgets so they use this message for backgrounds and we don't have to duplicate the effort everywhere.

Copy link
Contributor Author

@Ph4ntomas Ph4ntomas Oct 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ottatop do you have an input on this ?

Snowcap protobuf v1 was added after after the 0.1, so changing the current way we handle background in container & button would not be a breaking change. However doing so later would.

I can extract this in a standalone PR if you want it.

@Ph4ntomas Ph4ntomas force-pushed the snowcap-add-text_input-widget branch 2 times, most recently from 9c32f92 to 153ca98 Compare October 20, 2025 10:07
@Ph4ntomas Ph4ntomas force-pushed the snowcap-add-text_input-widget branch 2 times, most recently from 1fe3a6e to 3042cd0 Compare October 23, 2025 20:36
@Ph4ntomas Ph4ntomas force-pushed the snowcap-add-text_input-widget branch from 3042cd0 to 3ef8c4e Compare October 25, 2025 09:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants